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(54) Systeme et procede de gestion d'attributs dans un environnement oriente objet 



(57) La presente inventbn conceme un procede de 
gestion d'une base de donnees (4) ou annuaire ou equi- 
valent comportant des objets (5) caracterises par des 
attributs standards (6), la base etant apte k §tre interro- 
gee par une application, un utilisateur ou autre, appele 
entite, consistant £ caracteriser les objets (5) par des 



attributs specifiques (20) dits attributs opaques (20), 
presentant la meme structure externe que les attributs 
standards (6) et dont la structure interne permet de d6- 
finir et administrer des composants (21 ) de maniere in- 
dependante a la base (4). 

La presente invention conceme egalement le sys- 
teme mettant en oeuvre ledit procede. 
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Description 

[0001] La presents invention concerns le domaine 
des bases de donnees dans un environnement d'ordi- 
nateur oriente objet. 

L'art anterieur 

[0002] line base de donnees, un annuaire ou Equiva- 
lent organise de mani&re coherente des objets partag6s 
par des utilisateurs ou des applications. 
[0003] Un objet est une abstraction d'une donnee du 
monde reel. L'objet est caracterise par une identity, un 
etat et un comportement. L'identite d'un objet est repre- 
sente par un identifiant unique et invariant qui permet 
de referencer l'objet independamment des autres ob- 
jets. Les valeurs de l'6tat d'un objet sont donn6es par 
des attributs. Le comportement d'un objet est defini par 
un ensemble d'operations applicables k l'objet. Les ob- 
jets similaires sont groupes en classe. Une classe d6crit 
la structure et le comportement commun d'objets. Les 
objets et les attributs sont definis dans un schema de la 
base. 

[0004] Dans les bases de donnees actuelies, tous ies 
attributs sont declares dans le schema de la base. 
[0005] Or, la complexity et revolution rapide des in- 
formations contenues dans une base de donnees sou- 
levent de nombreux problemes : 
[0006] La description du schema de la base est fre- 
quemment modifies ce qui necessite une gestion per- 
manente et couteuse de la base et entraine une gene 
pour les utilisateurs et administrateurs. 
[0007] Des objets de versions differentes sont sus- 
ceptibles d'etre g6res par une m§me base. Le probieme 
de gestion de versions se complique avec la replication 
des bases dans un environnement distribue et plus par- 
ticulterement lorsque les differentes versions se situent 
sur des machines differentes. 
[0008] L'utilisateur a souvent besoin d'acceder rapi- 
dement k une suite d'attributs d'un objet donn6. La base 
est sollicitee pour la recherche de chacun des attributs. 
II en resulte un encombrement dans la consultation de 
la base, une lenteur dans I'obtention d'une reponse k 
une interrogation. 

[0009] II serait avantageux que des composants de 
types differents (chaine de caracteres, entier, boo- 
leen...) soient stockes dans un meme attribut, ce qui 
n'est pas realisable avec les systemes actuels connus. 
[0010] L'origine, I'integrite ou la confidentialite des in- 
formations stockees dans la base ne sont garanties 
qu'apres application de techniques diverses sur les at- 
tributs, techniques rapportees, lourdes et couteuses. 
[001 1 ] Un but de la presente invention est de permet- 
tre de modifier facilement et rapidement les informations 
associees k une classe d'objets. 
[0012] Un autre but de la presente invention est d'ac- 
ceder rapidement a une suite d'attributs. 
[001 3] Un autre but est d'integrer des composants de 



differents types dans un m§me attribut. 
[001 4] Un autre but de la presente invention est d'ad- 
ministrer la cohabitation d'objets de versions differentes 
dans une meme base ou des bases rSpliquees. 
5 [001 5] Un autre but est de garantir l'origine, I'integrite 
et la confidentiality de Information sans recours k des 
techniques rapportees. 

Resume de ('invention 
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[0016] Dans ce contexte, la presente invention propo- 
se un precede de gestion d'une base de donnees ou 
annuaire ou equivalent comportant des objets caracte- 
rises par des attributs standards, la base etant apte k 

is §tre interrogee par une application, un utilisateur ou 
autre appele entity, caracterise en ce qu'il consiste a 
caracteriser les objets par des attributs sp6cifiques dits 
attributs opaques, pr£sentant la meme structure exter- 
ne que les attributs standards et dont la structure interne 

20 permet de definir et administrer des composants de ma- 
niere independante k la base. 
[0017] La presente invention concerne le systeme in- 
fonmatique de mise en oeuvre du procede selon I'inven- 
tion. 

25 [0018] La presente invention se rapporte egalement 
k un systeme informatique comprenant au moins une 
machine munie d'une base de donnees ou annuaire ou 
Equivalent susceptible d'etre interrogee par une appli- 
cation, un utilisateur ou autre, appele entite, caracterise 

30 en ce qu'il comprend une interface de programmation 
au niveau applicatif API entre la base et I'entite compre- 
nant des fonctions d'acefcs k la base et des fonctions de 
gestion d'attributs standards et/ou d'attributs opaques. 



[001 9] D'autres caracteristiques et avantages de I'in- 
vention apparaltront k la lumifcre de la description qui 
suit, donnee a titre d'exemple illustratif et non limitatif 
40 de la presente invention, en reference aux dessins an- 
nexes dans lesquels: 

• la figure 1 est une vue schematique du systeme se- 
lon la presente invention ; 

45 • la figure 2 represente de mantere schematique la 
structure d'un attribut opaque du systeme selon la 
figure 1 ; 

• la figure 3 represente de maniere schematique des 
etapes du procede selon la presente invention. 

50 

Description d'une forme de realisation de Inven- 
tion 

[0020] Comme represente sur la figure 1 , la presente 
55 invention se rapporte a un systeme d'information 1 dont 
I'environnement est de type oriente objet. Le systeme 1 
comporte au moins une machine 2. Le terme « machine 
» est utilise dans un sens general pour designer tout 
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type d'ordinateurs ou equivalents. 
[0021] Le systeme 1 peut etre un systeme dont I'en- 
vironnement est de type distribue ou local. Dans la for- 
me de realisation illustree sur la figure 1, le systeme 1 
de type distribue comprend trois machines 2a, 2b, 2c, 
appelees respectivement machine 2a annuaire, machi- 
ne 2b de stockage, machine 2c d'administration. Seuls 
les composants des machines 2 du systeme 1 caracte- 
ristiques de la presente invention seront decrits, les 
autres composants etant connus de I'homme du metier. 
Les machines 2 sont relives entre elles au travers d'un 
reseau 3 ; dans la forme de realisation de la figure 1 , la 
machine 2a est reliee aux machines 2b et 2c par le re- 
seau 3. 

[0022] Le systeme 1 comporte une base de donnees 
ou un annuaire 4 ou equivalent instalie sur la machine 
2a annuaire. Dans la description qui suit, il sera fait re- 
ference a Tannuaire 4. L'annuaire 4 contient des objets 
5 caracterises par des attributs de type connu dits attri- 
buts standards 6. Dans I'exemple illustre sur la figure 1 , 
les informations sont structures en objets 5 integres 
dans Tannuaire 4 suivant le module X500 connu ; la ma- 
chine 2a annuaire communique avec les machines 2b 
de stockage et 2c d'administration au travers d'une in- 
terface 7 LDAR 

[0023] Des utilisateurs ou des applications diverses 
ou autres, appeles ci-apr6s entites 8 sont susceptibles 
d'interroger l'annuaire 4 directement sur la machine 2a 
annuaire I'hebergeant ou k partir d'autres machines 2b, 
2c. Dans I'exemple illustre sur la figure 1 , une applica- 
tion 8 est installee sur la machine 2c d'administration et 
travaille avec les donnees de l'annuaire 4. Seion une 
forme de realisation particuli6re, I'application 8 est mu- 
nie d'une interface graphique 9. 
[0024] L'une des machines 2a, 2b ou 2c du systeme 
1 (machine 2b de stockage sur la figure 1 ) comprend un 
compilateur 10 de description et des moyens de stoc- 
kage 11 d'au moins un fichier 12 source de description. 
[0025] L'une des machines 2a, 2b ou 2c du systeme 
1 (machine 2c d'administration sur la figure 1 ) comprend 
une interface de programmation au niveau applicatif, 
appeiee couramment interface AP1 1 3 munie d'au moins 
une fonction 14 de gestion et d'au moins une fonction 
15 d'acces k l'annuaire 4, des moyens 16 de memori- 
sation d'une structure 17 de communication entre Pin- 
terface AP1 1 3 et I'entite 8, une memoire tampon 18, un 
module de securite 19. 

[0026] Le procede selon la presente invention consis- 
te a caracteriser les objets 5 par des attributs specifi- 
ques 20 dits attributs opaques 20, presentant la meme 
structure exteme que les attributs standards 6 et dont 
la structure interne permet de definir et administrer des 
composants 21 de maniere independante a l'annuaire 4. 
[0027] Les structures des attributs standards 6 sont 
de trois types : de type texte directement lisible par In- 
terface 7, de type binaire representant une unique infor- 
mation d'un type determine qui n'est pas directement 
lisible par I'interface 7, de type specialise requerant des 



4 

contrdles de syntaxe. 

[0028] Le terme « structure externe >» signifie que 'la 
structure de Pattribut opaque 20 telle que vue par l'an- 
nuaire 4 et I'interface 7 est identique k la structure d'un 
5 attribut standard 6. Pour l'annuaire 4 et I'interface 7, les 
attributs opaques 20 presentent une structure externe 
de type binaire. Un attribut opaque 20 est considere par 
I'interface 7 entre I'entite 8 et l'annuaire 4 comme un at- 
tribut standard 6. 
w [0029] L'attribut opaque 20 est comparable k un 
container : des composants 21 sont introduits dans le 
container. Les composants 21 sont independants de la 
technologie ou de {'organisation de l'annuaire 4. II est 
possible de rajouter des composants 21 dans Pattribut 
'5 opaque 20 sans modifier le schema de l'annuaire 4. Les 
composants 21 introduits dans Pattribut opaque 20 peu- 
vent etre de types varies. 

[0030] L'objet 5 est identifie de maniere unique dans 
l'annuaire 4: les attributs opaques 20 sont crees k cha- 
20 que besoin specifique d'une entite 8. Le contenu des 
attributs opaques 20 depend de Pentite 8 contrairement 
k celui des attributs standards 6 dependant de l'annuai- 
re 4 et de son schema de base. 
[0031] L'attribut opaque, de type binaire pour P inter- 
ns face 7, presente une structure interne determinee sus- 
ceptible d'etre exploitee par I'interface AP1 13, structure 
dans Jaquelle divers types de composants 21 sont clas- 
ses. 

[0032] Selon une forme de realisation de I'invention 
30 iliustree sur la figure 2, la structure interne de Pattribut 
opaque 20 est constituee de trois parties : 

• un en-tete 22 ; 

• une table 23 de caracteristiques des composants 
35 21 ; 

• un ensemble 24 de valeurs des composants 21 . 

[0033] La structure interne de Pattribut opaque est 
predefinie de maniere k retrouver les composants 21 
40 dans les informations de type binaire de l'attribut opa- 
que 20 comme vu plus haut. 

[0034] L'en-tete 22 fournit des informations generates 
sur l'attribut opaque 20 concerne telies que : 

45 . une version du formalisme de la structure utilisee 
pour l'attribut opaque 20 et pour les composants 21 
contenus dans l'attribut opaque 20 concerne. La 
version assure une evolution de la structure de l'ob- 
jet et permet la compatibilite montante et descen- 

so dante des structures comme il sera vu plus loin ; 

• une longueur en octets des donnees suivantes de 
Pen-tele (informations de securite, date de derniere 
mise k jour ...) de maniere a retrouver (a table 23 
dans les donnees binaires de Pattribut, comme vu 

55 plus haut ; 

• des informations de securite assurant Pintegrite, 
I'origine et la confidentialite des composants conte- 
nus dans l'attribut opaque. Les attributs sont prote- 
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ges ^alterations ou d'extractions non souhaitees. 
Des services de signature et/ou de chiff rement sont 
susceptibles d'etre mis en oeuvre. Les informations 
de s6curite permettent la signature de I'attribut de 
maniere globale, ce qui ameliore les performances. 
Les informations de s6curit6 sont par exemple In- 
dication d'une signature souhaitee ou non pour I'at- 
tribut, indication d'un chiffrement souhaite pour 
tous les composants de I'attribut ou seulement cer- 
tains d'entre eux ou encore non souhaite, la force 
des algorithmes utilises, les algorithmes utilises (si- 
gnature DSA, RSA... ; chiffrement DES, IDEA...), 
retat des composants de I'attribut dans I'ensemble 
24 (signe ou non, chiffre ou non), la cle utilisee, la 
valeur de la signature,... 

• une date de derniere mise & jour de I'attribut opaque 
20 concerne ; ... 

[0035] La table 23 indique les caracteristiques des 
composants 21 contenus dans I'attribut opaque 20 en 
question. Les caracteristiques des composants 21 per- 
mettent notamment de retrouver un composant 21 de- 
termine dans I'ensemble 24 des composants 21 . La ta- 
ble 23 comprend : 

• I'identifiant d'un composant 21 sous la forme par 
exemple d'un numero ^identification ; 

• un type de codage du composant 21 concerns. Le 
type de codage d6crit le mode de representation 
des composants 21 dans I'attribut opaque 20. L'at- 
tribut opaque est susceptible de contenir des com- 
posants de types varies. Le type permet le controle 
du stockage des composants 21 dans I'attribut opa- 
que 20, Porganisation des composants 21 en liste ; 

• des informations complementaires de codage com- 
me par exemple des informations concernant le ty- 
pe multimedia ; 

• une longueur utile de valeur du composant 21 con- 
cerne exprimee en octets 

[0036] Les composants 21 sont stockes dans I'en- 
semble 24 les uns a la suite des autres dans I'ordre dans 
lequel ils ont ete cites dans la table 23. L'identifiant et 
la longueur utile indiques dans la table 23 permettent 
de retrouver un composant 21 determine dans I'ensem- 
ble 24. 

[0037] L'attribut opaque 20 permet de regrouper des 
composants 21 de types differents et de permettre 
I'ajout, la modification ou la suppression d'un attribut 6, 
20 et/ou d'un composant 21 sans intervenir sur le sche- 
ma de I'annuaire 4. 

[0038] Selon une forme de realisation, les types de 
codage determines dans la table 23 se divisent en trois 
categories : les types simples, les types multimedia, les 
types constructeurs. 

[0039] Les types simples comprennent le type texte 
(« TEXT » en annexe) qui correspond & une chaine de 
caracteres (texte quelconque), le type entier de valeur 



binaire, le type numerique (caracteres numeriques de 0 
k 9), le type bit qui correspond h un champ d'octets; le 
type booteen (valeur vrai ou faux), le type enum6re dont 
la valeur est associee k une constante, le type secret 

5 (texte special de type chiffre et de longueur quelcon- 
que), le type date/heure (format de date/heure etabli). 
[0040] Les types multimedia component le type ima- 
ge, le type son et le type video. 
[0041] Les types constructeurs introduisent et delimi- 

10 tent des structures telles que des listes. Le type liste (« 
LIST » en annexe) repr6sente une liste de n occurren- 
ces d'une structure, le nombre maximum d'occurrences 
etant fixe. Le type fin de liste (« END » en annexe) clot 
la description d'une liste. Les types constructeurs auto- 

15 risent I'imbrication des listes; n niveaux d'imbrication 
sont possibles. Des regies d'utilisation accompagnent 
les types constructeurs. 

[0042] Tout autre type est susceptible d'etre utilise. 
[0043] Les fonctions 15 d'acces permettent I'acces 

20 aux attributs 6, 20 de I'annuaire 4. Les fonctions 1 5 d'ac- 
ces permettent d'extraire, d'introduire, de modifier ou de 
supprimer des attributs dans I'annuaire 4. Les fonctions 
15 mettent les attributs extraits de I'annuaire 4 & ia dis- 
position des fonctions 14 de gestion dans la memoire 

25 tampon 18. Les fonctions 14 de gestion creent, modi- 
fient, suppriment des attributs et/ou des composants et 
transmettent le resultat des operations aux fonctions 1 5 
d'acces par I'interm6diaire de la memoire tampon 18 : 
les fonctions 15 d'acces introduisent les attributs et/ou 

30 composants crees ou modifies par les fonctions 1 4 dans 
I'annuaire 4, ou encore suppriment de I'annuaire 4 les 
attributs et/ou composants supprimes par les fonctions 
14de gestion. 

[0044] Les fonctions 1 4 de gestion sont prevues pour 
35 Texploitation des attributs opaques 20 de maniere inde- 
pendante & I'annuaire 4. 

[0045] Les fonctions 1 4 de gestion permettent d'intro- 
duire ou de supprimer des attributs standards 6 dans 
des objets 5, des composants 21 dans des attributs opa- 

40 ques 20 ou des attributs opaques 20 dans des objets, 
de lire ou modifier des attributs standards 6 ou des com- 
posants 21 des attributs opaques 20, en s'appuyant si 
necessaire sur une description 25 formelle compiiee et 
stockee dans I'annuaire 4. Les fonctions 14 de gestion 

45 sont susceptibles de lire les composants 21 des attributs 
opaques 20 sans faire appel a la description 25 corres- 
pondante: les fonctions 1 4 de gestion doivent alors con- 
naitre I'identifiant du composant recherche (i'identifiant 
d'un attribut opaque est donne par la table 23 dudit at- 

50 tribut). L'attribut opaque contient le minimum d'informa- 
tions permettant aux fonctions de gestion 14 de lire les 
composants qu'il contient sans informations supple- 
mentaires. II est a noter que la lecture est ('operation la 
plus frequente statistiquement. Pour toute autre opera- 

55 tion telle la creation, la modification ou la suppression 
d'un attribut 6, 20 ou d'un composant 21 , la fonction 1 4 
de gestion requiert les informations de la description 25 
compiiee. Lors d'operations de mise a jour (creation, 
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modification ou suppression), des contrdles sont neces- 
saires tels que des contr6les sur les longueurs, les ty- 
pes, les masques, les caractfcres obligators... : les 
controles s'appuient sur les informations comprises 
dans les descriptions 25 compilees. 
[0046] II est k noter que les informations contenues 
dans les descriptions 25 pourraient, selon une forme de 
realisation de ('invention, etre comprises dans les attri- 
buts opaques 20. Les descriptions 25 compiles ame- 
liorent les performances du syst&me 1. 
[0047] La description 25 de I'attribut opaque 20 est 
issue des fichiers source 12. Un fichier source 12 est 
reserve pour chaque description 25 et pour chaque ver- 
sion de la description 25. La compilation de la descrip- 
tion 25 s'effectue k partir des fichiers source 12 au 
moyen du compilateur 10. La compilation ameiiore les 
performances de traitement. 

[0048] La description 25 compilee apporte k I'entite 8 
des informations relatives a un attribut opaque donne 
sans que I'entite ait k solliciter I'annuaire 4: Je fichier 
source 12 contient des informations telles que le libelle 
externe de saisie du champ attribut ou composant « LBL 
» comme il sera vu plus loin, assurant une mise en forme 
automatique des formulaires de saisie de I'interface gra- 
phique 9 de I'entite 8: 1'interface 9 est generee automa- 
tiquement sans avoir recours aux attributs stockes dans 
I'annuaire 4. La meme description 25 est utilises pour 
!a saisie de donnees exterieures au systeme 1 et la ges- 
tion de donnees appartenant k I'annuaire 4, ce qui as- 
sure une coherence dans la gestion des informations. 
[0049] Dans la forme de realisation des figures 1 et 3, 
les fichiers source 12 sont enregistres dans la machine 
2b de stockage. Le compilateur 10 de la machine 2b 
transforme le fichier source contenu dans les moyens 
de stockage 11 en une description 25 compilee stockee 
dans I'annuaire 4 de la machine 2a annuaire. La des- 
cription compilee liee k un objet 5 donne est stockee par 
exemple (figure 1) dans un objet 26 special. Le fichier 
compile beneficie des capacites de distribution des 
technologies d'annuaires. 

[0050] La description 25 compilee permet une Evolu- 
tion en douceur du contenu des objets. Selon un exem- 
ple de forme de realisation, la description 25 comporte, 
comme il sera vu plus loin, le numero de version du con- 
tenu de I'objet 5 concerne : revolution de structure des 
objets 5 est geree a Taide de numeros croissants de ver- 
sion. 

[0051] La gestion des versions est rendue souple et 
efficace. L'annuaire 4 peut evoluer sans cesse sans re- 
mettre en cause les objets existants et le schema de 
I'annuaire. La gestion des versions est assuree par les 
fonctions 14 de gestion lors de la creation ou suppres- 
sion d'objets 5 dans I'annuaire 4. 
[0052] Selon un exemple de realisation de la gestion 
des versions, il est prevu une compatibilite montante en- 
tre la description 25 d'un objet 5 et I'objet 5 effectif exis- 
tant (objet 5 de version V et description 25 de version 
V-m): 



[0053] Dans ce cas, afin d'assurer une tojale compa^ 
tibilite, c'est k dire une evolution de la structure des ob- 
jets 5 sans remettre en cause les objets existants, les 
regies suivantes sont appliqu6es dans les fonctions de 
5 gestion 14: 

Si un nouveau composant 21 apparaTt dans la des- 
cription 25, il est visible pour I'entite 8 et indique 
comme absent dans I'objet 5 courant mais ajoute 
10 en mise k jour par ia fonction de gestion 14 
concemee ; 

- Si un composant 21 disparait de la description 25, 
ii n'est plus visible pour I'entite 8 et est supprime de 
I'objet 5 k la mise a jour par la fonction de gestion 
is 14 concemee. 

[0054] II est egalement prevu une compatibilite des- 
cendante entre la description d'un objet et I'objet effectif 
existant (objet de version V et description de version V- 
20 n): 

[0055] Cette situation intervient dans des periodes 
transitoires de deploiement d'une nouvelle version de 
description d'objet, et de differences dues k la replica- 
tion des objets. 
25 [0056] Dans ce cas, une compatibilite minimum est 
assuree, permettant un fonctionnement transitoire, en 
attendant la mise k niveau de la description. 
[0057] Les regies suivantes sont appliquees : 

30 - Si un composant 21 est present dans la description 
25 mais ne Test plus dans I'objet 5, le composant 
21 est consider comme absent de la description ; 
Si un composant est absent de la description mais 
present dans I'objet, il est considere comme present 

35 dans la description, accessible dans I'annuaire 4 au 
moyen de Pidentifiant mais pas du nom interne qui 
n'est defini que dans la description. 

[0056] Les modifications k apporter au schema de 
40 I'annuaire 4 sont limitees : les evolutions sont deportees 
hors de I'annuaire 4. 

[0059] Dans la forme de realisation de la figure 1 , les 
attributs d'une classe d'objets 5 sont regroupes en 
items. Une classe d'objets peut contenir plusieurs items. 
45 Dans la forme de realisation decrite, un item est cons- 
titue d'au moins un attribut standard 6 et/ou d'un seul 
attribut opaque 20. Un attribut standard 6 ou un compo- 
sant 21 dans un item est appeie dans ce qui suit un ele- 
ment de I'item. 

so [0060] D'autres items sont susceptibles d'etre crees. 
[0061] Les descriptions 25 sont de deux types : 

• les descriptions 25a d'items ; 

• les descriptions 25b d'attributs. 

55 

[0062] L'annexe 1 montre un exemple de description 
25 d'items et d'attributs. 

[0063] La description 25a d'items est ret erencee sous 
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la forme <Classe> - <ltem>, <Classe> reprdsente la 
classe de I'objet 5 concern^, <ltem> Pitem concern^ (en- 
semble de composants d'un atlribut opaque ou ensem- 
ble d'attributs standards dans ladlte classe d'objets en 
question). Les items cites sont declares au ptealable 
comme appartenant d la classe d'objets correspondante 
dans Tannuaire 4. Un fichier source 12 peut comporter 
une description d'items et une suite de descriptions d'at- 
tributs correspondents. 

[0064] La description 25 d'items comprend les infor- 
mations suivantes : 

• la classe de I'objet conceme, appelee « CLASS ». 
Les classes sont identifies par des mots cles re- 
serves. 

• les items declares dans un objet qui dependent de 
la classe de I'objet en question, appeles « ITEM » 
Une classe d'objets est constitute de plusieurs 
items. Pour chaque classe, la liste des items qu'il 
doit/peut contenir est definie. A chaque type d'item 
est associe un identifiant unique. Dans la forme de 
realisation decrite, les identifiants sont : 

« BASE »: attributs standards 6 ; 
- « XXX » (tout terme different du terme BASE 
utilise pour les attributs standards) : attributs 
opaques 20. 

• la version de la description de Titem, appetee « 
VERSION ». Cette information esttr&s importante : 
elle assure une evolution compatible de la descrip- 
tion des items. 

• la liste des langues k utiliser, appetee « LANGUA- 
GES » telles que par exemple la langue utiiisee 
pour les libelles d'attributs, ... ; une description re- 
quiert au moins une langue. Si une des langues 
n'est pas foumie explicitement pour un attribut, on 
prend par defaut la premiere langue definie dans la 
description pour I'attribut en question. 

[0065] La description 25 d'items peut egalement com- 
prendre des informations de securite optionnelles. Les 
informations sont dites optionnelles car elles impliquent 
une option par defaut en cas d'absence. Les informa- 
tions de securite sont definies dans Pen-tete 22 de I'at- 
tribut opaque 20 et/ou dans la description 25a d'items 
selon les besoins (options de securite generates et/ou 
pour seulement certains attributs). La protection des at- 
tributs opaques 20 s'effectue par chiffrement et/ou si- 
gnature. Par defaut, par exemple, les attributs opaques 
ne sont ni signes ni chiffres. Les parametres optionnels 
de la description 25a autorisent la modification des va- 
leurs de protection par defaut. 
[0066] Selon une forme de realisation, les parametres 
optionnels sont : 



• la signature de I'attribut en question ; . 

• le chiffrement de I'attribut concern^ ; dans le cas 
d'un chiffrement requis, les composants 21 de type 
secret ne sont pas chiffres individuellement. 

5 • le niveau de chiffrement pour I'attribut en question. 

[0067] La description 25b d'attributs permet : 

• d'identifier chaque Element de I'objet concerns par 
10 un nom interne et un identifiant, d'indiquer la cor- 
respondence entre le nom interne et Pidentifiant 
pour un Element donne ; 

• de ddfinir les types des elements de I'objet 
concern^ ; 

is • de foumir des informations utiiisables par les fonc- 
tions de gestion 14 des elements 21 ou directement 
par I'entite 8 (interface graphique 9) telles que : 

un libelte(s) du champ de saisie de I'element ; 
20 - une indication du statut obligatoire ou optionnel 
de I'element ; 

une taille minimum / maximum ; 
des contraintes sur I'element ; 
des informations comptementaires sur Pele- 
25 ment. 

[0068] La description comprend : 

• le nom interne de I'element conceme, appele « ATT 
30 ». Le nom interne permet de nommer simplement 

un element (attribut standard 6 / composant 21 d'un 
attribut opaque 20). II sert de reference pour la ges- 
tion ulterieure des descriptions d'items et pour Pad- 
ministration de Pannuaire 4. Le nom interne est in- 

35 dependant du nom defini dans le schema de Pan- 
nuaire 4. Le nom interne identifie chaque element ; 
il est unique pour un objet 5 donne. Selon un exem- 
ple illustratif, le nom est donne sur 12 caracteres 
maximum. Le nom doit commencer sur le premier 

40 caractere de la ligne ; 

• Pidentifiant, appele I'OID. L'identifiant identifie cha- 
que element ; il est unique pour un item donne. 
L'identifiant est independant de Pidentification dans 

45 Pannuaire 4. 

• le nom de Pelement dans Pannuaire 4 utilise par In- 
terface 7 et obligatoire dans la description des at- 
tributs 6 standards, appele « XNM » II est code par 

50 exemple sur 36 caracteres maximum ; 

• indication de Petat de I'element au niveau de I'en- 
tite 8, appele « HID »>. L'etat de Pelement peut pren- 
dre les valeurs caches ou visibles. L'HID est declare 

55 avant les options qui suivent ; 

• le libelle externe de saisie du champ element tei que 
presente au niveau de I'entite 8, appele « LBL >» ; 
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• le type de codage de Tel6ment parmi ceux 6nonc6s 
pr6c6demment, appelS « TYP » 

[0069] D'autres options sont susceptibles d'§tre utili- 
s6es telles que par exemple des options qui sont fonc- 
tion du type de codage de lament. Quelques exem- 
ples sont donn6s ci-apr&s permettant de comprendre 
I'exemple de fichiers source donn6 en annexe. 

• Toption « MDT » determine le statut obligatoire ou 
optionnel de TSISment ; 

• Toption « RNG » represente la plage de longueur 
(chaine de caract&res, numerique, secret) ou de va- 
leur (entier), ou ie nombre d'occurrences minimal et 
maxima! (type const ructeur). 

• Toption « SZF » definit la taille du champ de saisie 
pour Tinterface graphique 9 de Tentite 8. 

• « CAS » definit la casse pour les types chaines de 
caracteres ; 

« FREE », la casse est respectee ; 
« UP », les majuscules sont forcees ; 
« LOW », les minuscules sont forc6es. 

[0070] Les informations donnees par la description 
telles que Toption SZF par exemple permettent la mise 
en forme automatique (sans avoir recours k des modu- 
les supplementaires) des formulaires de saisie de Tin- 
terface graphique. 

[0071] Des options sont k prSvoir ggalement par 
exemple pour les types multimedia tels que : 

• Toption « PLD » indiquant le pr6chargement auto- 
matique des types multimedias dans la structure. 

• Toption « ALG » qui est un identifiant d'algorithme. 

[0072] Les identifiants d'algorithme pour le type ima- 
ge sont par exemple : 



0 


GIF 


1 


JPG 


2 


TIF (fractales) 


3 


Ondelettes 



Des identifiants sont egalement determines pour les ty- 
pes sons et video. 

[0073] La manipulation des elements s'effectue k 
Taide des fonctions de gestion 14 en precisant Pitem. 
L'item doit etre precise a Tappel afin que les fonctions 
determinent la structure concernee par {'operation k ef- 
fectuer. 

[0074] Les fonctions de gestion 1 4 permettent de ma- 
nipuler (creer, lire, modifier, supprimer, afficher) les don- 
nees suivantes : 



attributs standards des objets de Tannuaire 4 ; 
attributs opaques des objets de Tannuaire 4 et com- 
posants 21 de ces attributs ; 
composants de s6curite de base integrSs dans des 
5 attributs des objets 5. . . 

[0075] Les Elements manipules par les entites 8 sont 
controles, filths par les fonctions 14 de gestion. 
[0076] Si la fonction de gestion 1 4 appelee nScessite 

to les descriptions 25a et b compilees de Tobjet, lesdites 
descriptions sont charges automatiquement par la 
fonction de gestion en question. Selon une forme de 
realisation particuliere de realisation, les descriptions 
compilees sont charg6es dans la memoire tampon 18. 

is Les fonctions de gestion 14 puisent dans les descrip- 
tions compiles les informations necessaires aux ope- 
rations qu'elles doivent effectuer. Les fonctions de ges- 
tion 1 4 s'appuient sur la description 25a d'item pour con- 
naitre la classe d'objet et Titem concernes. 

20 [0077] Les fonctions de gestion dans la forme de rea- 
lisation decrite sont les suivantes : 

- une fonction ^initialisation d'objets InitObj : Tappel 
k cette fonction permet d'initialiser la structure d'un 
25 nouvel objet ainsi que la structure d'attributs 6,20 
de Tobjet cree de maniere k pouvoir y inserer des 
attributs standards 6 ou des composants 21 . L'objet 
5 est dSfini k Tappel de la fonction ^initialisation en 
precisant la classe de Tobjet, Titem correspondant. 

30 

une fonction de rangement PutElem : la fonction de 
rangement realise la creation ou mise k jour d'un 
attribut 6,20 ou d'un composant 21 d'un attribut opa- 
que 20. A Tappel de la fonction de rangement sont 

35 precises la version, la classe, Tidentifiant ou le nom 
de T6!6ment, Toccurrence en cas de liste, la lon- 
gueur utile dans le cas de types bit ou secret, le type 
de codage de Telement. La fonction de rangement 
actualise pour chaque objet traite une liste des at- 

40 tributs modifiees afin d'optimiser la mise k jour. 

une fonction de lecture GetElem : la fonction de lec- 
ture assure Textraction d'un attribut 6, 20 ou d'un 
composant 21 d'un attribut opaque 20 de Tannuaire 

45 4. Si le composant demande est recherche par son 
identifiant d'objets, la fonction de lecture n'a pas a 
charger la description compilee : la table 23 inte- 
gree de Tattribut est suffisante. A Tappel de la fonc- 
tion de lecture, sont precises la version, la classe, 

50 Tidentifiant ou le nom de Telement, Toccurrence en 
cas de liste, la longueur utile dans le cas de types 
bit ou secret, le type de Telement. 

une fonction de suppression RemElem : la fonction 
55 de suppression effectue la suppression de la valeur 
d'un attribut 5,20 ou d'un composant 21 d'un attribut 
opaque 20, d'une occurrence d'une liste de compo- 
sants dans un objet. A Tappel de la fonction de sup- 



25 



30 
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pression, sont pr6cis6s la version, la classe, Piden- 
tifiant ou le nom de I'ei6ment, I'occurrence en cas 
de liste, la longueur utile dans le cas de types bit ou 
secret, le type de codage de I'Slement. 

- une fonction de verification CheckObj : la fonction 
de verification vSrifie les attributs 6,20 d'un objet et 
les composants 21 d'un attribut opaque 20 avant 
validation d'une creation ou d'une modification. La 
fonction de verification permet le contrdle de pre- 
sence obligatoire des attributs/composants. Elle 
peut etre appelee par une entite 8, mais elle peut 
egalement etre mise en oeuvre systematiquement. 
A I'appel de la fonction de verification, sont precises 
la version, la classe, I'identifiant ou le nom de l'6ie- 
ment, I'occurrence en cas de liste, la longueur utile 
dans le cas de types bit ou secret, le type de codage 
de ('element. 

[0078] Uentite 8 appelle une fonction 1 4 de gestion 
en pla$ant les parametres necessaires k ladite fonction 
1 4 dans la structure de communication 1 7. La structure 
de communication 17 se presente sous la forme d'une 
succession de tous les parametres necessaires a toutes 
les fonctions 14 de gestion. La fonction 14 de gestion 
appelee recupere dans la structure 17 de communica- 
tion les valeurs de parametres qui I'interessent. 
[0079] Les fonctions 1 4 de gestion renvoient un code 
retour indiquant si ia fonction a ete correctement effec- 
tuee, si une erreur est intervenue, si les parametres 
d'appel sont corrects, si la description compilee a ete 
retrouvee, si I'objet existe ... 

[0080] Les fonctions 14 de gestion sont congues de 
maniere k suivre les regies de gestion de versions enon- 
c£es plus haut. 

[0081] Les fonctions 14 de gestion permettent de lire 
une suite d'attributs/ composants sans solliciter I'an- 
nuaire 4. 

[0082] Les fonctions 1 4 de gestion assurent le chiff re- 
ment/dechiffrement et la signature des composants 21 
contenus dans i'attribut opaque 20. Les fonctions de 
gestion communiquent avec le module de security 19 
pour effectuer les operations de securite (signature, 
chiffrement, ...) requises dans une description d'item 25 
et/ou dans I'en-tete 22 d'un attribut opaque. II est k noter 
que le module de securite 19 est ind£pendant : I'entite 
8 peut faire appel directement au module de securite 
comme le montre la figure 1 . 

[0083] Le systfcme 1 decrit fonctionne de la manfere 
suivante : 

[0084] Lorsque I'entite 8 souhaite creer un objet dans 
Tannuaire 4, I'entite 8 commence par appeler la fonction 
de gestion 14 ^initialisation : I'entite 8 introduit les pa- 
rametres d'appel suffisants dans la structure de com- 
munication 17. La fonction 14 d'initialisation extrait de 
ladite structure les parametres qui lui sont necessaires, 
charge la description 25 compilee correspondante dans 
la memoire tampon 18 et cree la structure de depart 



d'objet souhaitee en definissant des valeurs par defaut. 
La structure est enregistrSe dans la memoire tampon 
18. La structure creee, la fonction 14 ^initialisation in- 
dique k I'entite 8 que la structure est pr§te k recevoir 

5 des attributs standards 6 ou des composants 21 en ren- 
voyant un code retour adapte dans la structure de com- 
munication 17. Comme indique plus haut, divers codes 
retour sont susceptibles d'etre transmis a I'entite 8 pour 
lui indiquer retat de fonctionnement. Lorsque I'entite de- 

10 tecte le code retour indiquant que la structure de depart 
a ete creee, I'entite 8 appelle alors la fonction 1 4 de ges- 
tion de rangement: elle transmet k la structure de com- 
munication les caracteristiques des attributs standards 
6 ou des composants 21 qu'elle souhaite introduire dans 

15 I'attribut opaque 20 concerne. La fonction 1 4 de range- 
ment les recupere et remplit ia structure d'objets prece- 
demment creee dans la memoire tampon 18 en s'ap- 
puyant sur la description compilee chargee. La fonction 
1 4 de rangement peut egalement faire appel au module 

20 19 de securite en cas de signature ou de chiffrement 
des informations contenues dans I'objet concerne. Lors- 
que I'objet est pr§t k etre transfer dans I'annuaire 4, 
I'entite 8 a le choix entre valider la creation ou la verifier 
sachant qu'en validant, I'operation de verification est 

25 egalement realisee. La verification avant validation per- 
met d'obtenir pr6cisement toutes les erreurs realisees. 
L'operation de verification est effectuee par la fonction 
de gestion de verification. Lorsque I'entite 8 valide la 
creation, la fonction 15 d'acces transffcre I'objet cree et 

30 renseigne dans I'annuaire 4. 

[0085] Lorsque I'entite 8 souhaite modifier un objet 
dans I'annuaire 4, I'entite 8 commence par appeler la 
fonction 15 d'acces. La fonction 15 d'acces retrouve 
I'objet dans I'annuaire 4 et en transfere une copie dans 

35 la memoire tampon 18. La fonction 15 d'acces indique 
par code retour k I'entite 8 que I'objet a ete correctement 
transfer dans la memoire tampon 18. L'entite 8 appelle 
alors la fonction 1 4 de gestion de rangement : elle trans- 
met k la structure de communication 17 les caracteris- 

40 tiques modifiees de I'attribut standard 6 ou du compo- 
sant 21 de I'attribut opaque 20 concerne. La fonction 14 
de rangement extrait les parametres qui lui sont neces- 
saires de la structure de communication 17 et charge ia 
description compilee correspondante dans la memoire 

4S tampon 18. La fonction 1 4 de rangement modifie I'objet 
en question enregistre dans la memoire tampon 18 par 
ia fonction d'acces 1 5, comme indique par les parame- 
tres de la structure de communication transmis par I'en- 
tite 8 et conformement a la description compilee. La 

so fonction de rangement peut egalement faire appel au 
module de securite 19 en cas de signature ou de chif- 
frement des informations contenues dans I'objet concer- 
ne. Lorsque I'objet est pret a etre transfer dans I'an- 
nuaire 4, I'entite 8 a le choix entre valider la creation ou 

55 la verifier sachant qu'en validant, l'operation de verifica- 
tion est egalement realisee. La verification avant valida- 
tion permet d'obtenir precisement toutes les erreurs rea- 
lisees. L'operation de verification est effectuee par la 
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fonction de gestion de verification. Lorsque i'entite 8 va- 
lide la modification, la fonction 1 5 d'acces transtere I'ob- 
jet modifie de la m6moire tampon 18 dans Pannuaire 4. 
[0086] Lorsque I'entite 8 souhaite supprimer un attri- 
but 6, 20 ou un composant 21 de I'annuaire 4, I'entite 8 
commence par appeler la fonction 15 d'acces. La fonc- 
tion 15 d'acces retrouve I'objet dans I'annuaire 4 et en 
transtere une copie dans la memoire tampon 18. La 
fonction 15 d'acces indique par code retour k I'entite 8 
que I'objet a ete correctement transfer dans la memoire 
tampon 18. L'entite 8 appelle alors la fonction 1 4 de ges- 
tion de suppression : elle transmet k la structure de 
communication les caracteristiques de I'attribut stan- 
dard 6 ou du composant 21 a supprimer de I'attribut opa- 
que 20 concerne. La fonction 14 de suppression extrait 
les parametres qui lui sont necessaires de la structure 
de communication 17 et charge la description compilee 
correspondante dans la memoire tampon 18. La fonc- 
tion 14 de suppression supprime le composant 21 ou 
Tattribut 6,20 en question enregistre dans la memoire 
tampon 18 par la fonction d'acces 15, comme indique 
par les parametres de la structure de communication 
transmis par I'entite 8 et conformement k la description 
compilee. La fonction 15 d'acces supprime I'attribut 6, 
20 ou le composant 21 indique dans la memoire tampon 
18 dans i'annuaire 4. 

[0087] Lorsque I'entite 8 souhaite lire un objet dans 
I'annuaire 4, I'entite 8 commence par appeler la fonction 
15 d'acces. La fonction 15 d'acces retrouve I'objet dans 
I'annuaire 4 et en transf ere une copie dans la memoire 
tampon 18. La fonction d'acces indique par code retour 
k I'entite 8 que I'objet a ete correctement transfere dans 
la memoire tampon 18. L'entite 8 appelle alors la fonc- 
tion de gestion 14 de lecture. Si les parametres foumis 
par I'entite 8 sont suffisants et en particulier si le nom 
interne de I'attribut standard ou du composant a ete don- 
ne, la fonction de lecture n'a pas besoin de charger la 
description compilee. Dans le cas contraire, la descrip- 
tion compilee est chargee de maniere k obtenir la cor- 
respondance entre le nom interne et I'identifiant. La 
fonction 1 4 de lecture verifie eventuellement si I'entite 8 
a le droit de lire les informations concernees en faisant 
appel au module de securite 1 9. Elle dechiff re eventuel- 
lement lesdites informations et verifie leur integrate. Elle 
retrouve les informations souhaitees de I'objet en par- 
courant i'ensemble 24 des valeurs k I'aide de I'identifiant 
ou libelie et de la longueur utile. Elle place lesdites in- 
formations dans la structure de communication 17. L'en- 
tite 8 n'a plus qu'£ lire les informations requises dans la 
structure de communication 17. 
[0088] Selon un developpement de 1'invention, les 
versions de description anterieures a une version utili- 
see k un instant t sont archivees dans un repertoire 
separe . Les versions de description anterieures peu- 
vent etre archivees par exemple en ajoutant au nom un 
suffixe representant le numero de version. 
[0089] La presente invention concerne done un pro- 
cede de gestion de I'annuaire 4 ou equivalent compor- 
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tant les objets 5 caracterises par les attributs standards 
6, I'annuaire 4 6tant apte k §tre interroge par I'entite 8, 
caracterise en ce qu'il consiste k caracteriser les objets 
5 par les attributs sp6cifiques 20 dits attributs opaques 
5 20, presentant la meme structure exteme que les attri- 
buts standards 6 et dont la structure interne permet de 
definir et administrer les composants 21 de maniere in- 
dependante k I'annuaire 4. 

[0090] Le precede selon I'invention consiste k definir 
10 et administrer les composants 21 au moyen de interfa- 
ce de programmation au niveau applicatif API 13 entre 
I'annuaire 4 et I'entite 8. 

[0091] Le precede consiste k definir la structure inter- 
ne de I'attribut opaque en trois parties : 

15 

- I'en-tete 22 deiivrant des informations generales sur 
I'attribut opaque 20 ; 

- la table 23 de caracteristiques des composants 2 1 ; 
I'ensemble 24 de valeurs des composants 21 indi- 

20 ques dans la table 23. 

[0092] Le precede consiste k integrer dans la struc- 
ture interne de I'attribut opaque 20 des informations de 
securite assurant Pintegrite, I'origine et/ou laconfidenti- 
25 alite des composants 21 contenus dans I'attribut 20. 
[0093] Le precede consiste k integrer dans la struc- 
ture interne de I'attribut opaque 20 des informations per- 
mettant la gestion de differentes versions du contenu de 
I'attribut 20. 

30 [0094] Le procede consiste k integrer dans la struc- 
ture interne de I'attribut opaque 20 le type de codage de 
chaque composant 21 contenu dans ledit attribut 20. 
[0095] Le procede consiste k lire ou mettre a jour, a 
savoir cr6er, modifier, lire ou supprimer, un attribut stan- 
ds dard 6, un attribut opaque ou un composant 21 dans un 
attribut opaque 20 de maniere independante k I'annuai- 
re 4 au moyen des fonctions de gestion 14 des attributs 
opaques 20 appelees par I'entite 8. 
[0096] Les fonctions 14 de gestion s'appuient sur la 
40 description 25 des attributs 6,20 pour effectuer leur mise 
k jour, ainsi que leur lecture si I'entite 8 n'a pas fourni 
les informations suffisantes pour acceder directement a 
Tattribut concerne dans i'annuaire 4. 
[0097] Le precede consiste k compiler la description 
45 25 a I'aide d'un compilateur 1 0. 

[0098] Le procede consiste k integrer dans la descrip- 
tion 25 des informations de securite assurant I'integrite, 
I'origine et/ou la confidentialite des composants 21 con- 
tenus dans I'attribut 20. 
so [0099] Le procede consiste, au moyen des fonctions 
15 d'acces a I'annuaire 4, a extraire, introduire, modifier 
ou supprimer des attributs 6,20 dans I'annuaire 4 con- 
formement aux operations effectuees par les fonctions 
14de gestion. 

55 [0100] La presente invention porte egalement sur le 
systeme informatique permettant la mise en oeuvre du- 
dit procede. 

[0101] La presente invention se rapporte a un syste- 
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me informatique comprenant au moins une machine 2 
munie de Tannuaire 4 ou Equivalent susceptible d'etre 
interroge par I'entite 8, caract£ris6 en ce qu'il comprend 
I'interface de programmation au niveau applicatif AP1 1 3 
entre Tannuaire 4 et Tentite 8 comprenant les fonctions 
15 d'acc&s k Tannuaire 4 et les fonctions 14 de gestion 
d'attributs standards 6 et/ou d'attributs opaques 20. 
[0102] L'entite 8 communique avec Tinterface AP1 1 3 
au travers de la structure de communication 1 7 enregis- 
tr6e dans les moyens de memorisation 16. 
[01 03] Le systeme comprend les moyens 1 1 de stoc- 
kage des fichiers source 12, le compilateur 10 desdits 
fichiers 12. 

ANNEXES 

Exemples de fichier source 12. 

[0104] / description 25 de i'item BASE de la classe 
d'objets Personne 

CLASS=PERSONNE 
ITEM=BASE 
VERSION=001 
LANGUAGES=EN,FR 

/description 21 des attributs standards 6 de I'item 
BASE 

ATT=CNAME 
OID=0001 

XNM=commonName 
HID=N 

LBL=EN="User common name' 

LBL=FR="ident X500 de I'usager" 

TYP=TEXT 

MDT=Y 

RNG=64 

SZF=24 

CAS=FREE 

ATT=SURNAME 
OID=0002 
XNM=surname 
HID=N 

LBL=EN="User surname* 

LBL=FR="Patronyme X500 de I'usager" 

TYP-TEXT 

MDT-Y 

RNG=32 

SZF=16 

CAS=LOW 

ATT=TELEPHONE 
OIO=0003 

XNM= telephoneNumber 
HID-N 

LBL=EN-'User telephone" 



LBL=FR="Telephone usager" 
MDT=N 
RNG=16 
SZF=16 
5 CAS=UP 

/ description 25 d'un item attribut opaque SECITEM 20 
de la classe d'objets PERSON 
/ description des composants de I'attribut opaque, dans 
io I'item SECITEM 

CLASS=PERSON 
ITEM=SECITEM 
VERSION=001 
15 LANGUAGES=EN,FR 

/ description 25 des attributs opaques 20 de Titem 
/ definition de la liste des ressources accordees 

20 ATT=LISTRAL 
OID=100 

LBL=EN="Resource allocated list" 
LBL=FR= , Liste des ressources allouees" 
TYP=LIST 
25 PRS=PCM 
RNG=500 

/ classe des ressources de la liste 

30 ATT=OBJECTCLASS 
OID=101 

LBL=EN="Resource class" 
LBL=FR="Classe de la ressource" 
TYP=TEXT 
35 RNG=48 
CAS=UP 

/ nom de la ressource 

40 ATT=OBJECTID 
OID=102 

LBL=EN="Resource name" 
LBL=FR="Nom de la ressouce" 
TYP=TEXT 
45 MDT=N 
SZF=48 
RNG=96 
CAS=UP 

50 / fin description de la liste (d'une occurrence liste) 

ATT=ENDOFLIST 
010=100 
HID=Y 
55 TYP=END 

/ exemple de description des droits d'acces aux noeuds 
et objets 
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/ droit sur le niveau noeud 

ATT=NODERGT 

OID=102 

HID=N 

LBL=EN="Rights on node - 

LBL=FR="Droits sur le noeud" 

TYP=TEXT 

MDT=N 

RNG=8 

CAS=UP 

ATT=CHILDGRGT 

OID=103 

HID=N 

LBL=EN= i General rights on attached objects" 

LBL=FR="Droits generaux sur les objets ratta- 

ch6es" 

TYP=TEXT 

MDT=N 

RNG=8 

CAS=UP 

ATT=CLASSRGT 

OID=104 

HlD=N 

LBL=EN='Specific rights on attached objects" 

LBL=FR="Droits specifiques sur les objets ratta- 

chees" 

TYP=TEXT 

MDT=N 

RNG=8 

CAS=UP 



Revendications 

1. Procede de gestion d'une base de donnees (4) ou 
annuaire ou equivalent comportant des objets (5) 
caracterisSs par des attributs standards (6), la base 
(4) etant apte k etre interrogee par une application, 
un utilisateur ou autre appel6 entite (8), caracterise 
en ce qu'il consiste k caract6riser les objets (5) par 
des attributs specifiques (20) dits attributs opaques 

(20) , prSsentant la meme structure exteme que les 
attributs standards (6) et dont la structure interne 
permet de definir et administrer des composants 

(21) de maniere independante k la base (4). 

2. Procede selon la revendication 1 , caracterise en ce 
qu'il consiste k definir et administrer les compo- 
sants (21) au moyen d'une interface de program- 
mation au niveau applicatif API (13) entre la base 
(4) et I'entite (8). 

3. Procede selon Tune des revendications 1 ou 2, ca- 
racterise en ce qu'il consiste k definir la structure 
interne de I'attribut opaque en trois parties : 



10 



15 



- un en-t§te (22) d§livrant des informations ge- 
nerates sur i'attribut opaque (20); 
une table (23) de caract6ristiques des compo- 
sants (21) ; 

un ensemble (24) de valeurs des composants 
(21) indiquSs dans la table (23). 

4. Proc6d6 selon Tune des revendications 1 k 3, ca- 
racterise en ce qu'il consiste k integrer dans la 
structure interne de I'attribut opaque (20) des infor- 
mations de security assurant I'integrite, I'origine et/ 
ou la confidentiality des composants (21 ) contenus 
dans I'attribut (20). 

5. Procede selon i'une des revendications 1 k 4, ca- 
racterise en ce qu'il consiste k integrer dans la 
structure interne de I'attribut opaque (20) des infor- 
mations permettant la gestion de differentes ver- 
sions du contenu de I'attribut (20). 
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6. Procede selon I'une des revendications 1 a 5, ca- 
racterise en ce qu'il consiste k integrer dans la 
structure interne de I'attribut opaque (20) le type de 
codage de chaque composant (21) contenu dans 

25 ledit attribut (20). 

7. Procede selon Tune des revendications 1 a 6, ca- 
racterise en ce qu'il consiste k lire ou mettre k jour, 
£savoircreer, modifier, lireou supprimer, un attribut 

30 standard (6), un attribut opaque ou un composant 
(21) dans un attribut opaque (20) de maniere inde- 
pendante k la base (4) au moyen de fonctions de 
gestion (14) des attributs opaques (20) appelees 
par I'entite (8). 

35 

8. Procede selon la revendication 7, caracterise en ce 
que les fonctions (14) de gestion s'appuient sur une 
description (25) des attributs (6,20) pour effectuer 
leur mise k jour, ainsi que leur lecture si I'entite (8) 

40 n'a pas fourni les informations suffisantes pour ac- 
ceder directement k I'attribut concerne dans la base 
(4). 

9. Procede selon la revendication 8, caracterise en ce 
45 qu'il consiste a compiler la description (25) k i'aide 

d'un compilateur (10). 

10. Procede selon Tune des revendications 8 ou 9, ca- 
racterise en ce qu'il consiste a integrer dans la des- 

50 cription (25) des informations de securite assurant 
Tintegrite, I'origine et/ou la confidentiality des com- 
posants (21) contenus dans I'attribut (20). 

1 1 . Procede selon la revendication 7, caracterise en ce 
55 qu'il consiste, au moyen de fonctions (15) d'acces 

k la base (4), a extraire, introduire, modifier ou sup- 
primer des attributs (6,20) dans la base (4) confor- 
mement aux operations effectuees par les fonctions 
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(14) de gestion. 

12. Syst&me informatique comprenant au moins une 
machine (2) munie d'une base de donnSes (4) ou 
annuaire ou Equivalent susceptible d'etre interro- s 
g£e par une application, un utilisateurou autre, ap- 
pelS entite (8), caract6ris6 en ce qu'il comprend une 
interface de programmation au niveau applicatif 
API (13) entre la base (4) et I'entite (8) comprenant 
des fonctions (15) d'accds k la base (4) et des tone- 10 
tions (14) de gestion d'attributs standards (6) et/ou 
d'attributs opaques (20). 

13. Systeme selon la revendicatbn 12, caracterise en 

ce que I'entite (8) communique avec interface API '5 
(13) au travers d'une structure de communication 
(1 7) enregistrSe dans des moyens de memorisation 
(16). 

14. Systdme selon Tune des revendications 12 ou 13, 20 
caract6ris6 en ce qu'il comprend des moyens (11) 

de stockage de fichiers source (12), un compilateur 
(10) desdits fichiers (12). 

15. Syst&me informatique permettant la mise en oeuvre 2s 
du procedd selon Tune des revendications 1 h 11. 
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En-tete 

- Version ; 

- Longueur en octets ; 

- Informations de securite ; 

- Date de demiere mise a jour ; ... 

Table 

■ Identifiant; 

■ Type de codage ; 

■ Informations complementaires de codage ; 
M Longueur utile : ... 

Ensemble de valeurs 



FIG.2 
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